1. Field of the Invention
The present invention relates generally to a mobile terminal apparatus and method capable of an Internet Protocol (IP)-based video call service. More particularly, the present invention relates to a method and apparatus for image format determination for determining an image format for exchange between mobile video telephones.
2. Description of the Related Art
Recently, the so-called ‘camera phone’, designed by adding a camera function to a mobile communication terminal, is becoming increasingly common. The camera phone has developed beyond recording pictures for transfer to a computer via a port or a means for transmitting/receiving video data, transcending the original capability of a mobile communication terminal transmitting/receiving voice and data. Therefore, the video call service is now available, in which users can enjoy not only the voice call but also a video call over the camera phones.
With reference to FIG. 1, herein below is a brief description of an initialization process for a video call between the general IP-based mobile video telephones.
Referring to FIG. 1, a User Equipment 1 (UE1) 101 sends a Session Description Protocol (SDP) invite offer to a UE2 103 via an outbound proxy 102 in steps 110 and 120.
The SDP invite offer is a message including control information for video transmission, such as the number of frames per second, picture quality, image format, etc. The mobile video telephone properly distributes its limited bit rate among image, voice, data and control signals for their transmission based on the Internet Protocol (IP). Of the full bit rate, a bit rate allocation for video transmission is determined by taking into account the number of frames per second, picture quality, image format, etc. Among these items, the number of frames per second and the picture quality can be adjusted even during a video call, but the image format is generally fixed during the call.
Session Initiation Protocol/Session Description Protocol (SIP/SDP) is used for controlling the number of frames per second as well as the picture quality. In this particular case, a UE sends a command ‘a=quality:<quality>’ indicating information on the number of frames per second and the picture quality to its opposing UE along with the SDP offer of FIG. 1. In the command, ‘<quality>’ has a value ranging from 0 to 10, where 0 corresponds to greatest number of frames per second and the lowest picture quality, and 10 corresponds to the least number of frames per second and the highest picture quality. Then the opposing UE controls the number of frames second and the picture quality according to the <quality> information included in the SDP offer.
The image format includes the number of horizontal and vertical pixels of an image transmitted/received during a video call, and a UE uses the SDP offer to provide information on its desired image format to the opposing UE. An example of the SDP offer is given below.
<SDP offer>
m=video 49154 RTP/AVP 99 100
b=AS:92
a=rtpmap:99 H263-2000/90000
a=fmtp:99 profile=0; level=45
a=rtpmap:100 MP4V-ES/90000
a=fmtp:100 profile-level-id=9; \
config=000001b009000001b509000001000000012000845d4c282c2090a28
Regarding the above-SDP offer, a UE requests an opposing UE to select one of an H.263 video encoder (profile=0, level=45) and a MPEG-4 video encoder (profile-level=9) at a bit rate of 92 kbps. In the SDP offer, ‘profile’ and ‘level’, which define performances of the video encoders, prescribe the maximum image format available for encoding/decoding, the maximum number of frames per second, the maximum number of processable blocks, etc.
A sending UE commonly encodes transmission data with a maximum image format allowed by the profile and level values. For example, the maximum image format may include SQCIF (128×96), QCIF (176×144), QVGA (320×240), CIF (352×288), VGA (640×480), etc.
Referring back to FIG. 1, in step 130, the UE2 103 analyzes the received SDP offer, and performs an operation corresponding to the analysis result.
A detailed description of the analysis process of step 130 will now be given below with reference to FIG. 2.
Referring to FIG. 2, the UE2 103 checks the received SDP offer in step 210, and determines in step 220 whether the received SDP offer is acceptable. The acceptability is based on the attributes of the equipment. For example, for an image format, the UE2 103 determines if the maximum image format requested by the UE1 101 is an image format that the UE2 103 can accept.
If it is determined in step 220 that it is possible to accept the SDP offer, the UE2 103 initializes its codec in step 230, and sends a response message (200 OK) indicating acceptability of the SDP offer to the UE1 101 via the outbound proxy 102 in step 240 (steps 140 and 150 of FIG. 1).
However, if it is determined in step 220 that it is impossible to accept the SDP offer, for example, if the maximum image format, for example, is greater than or equal to the image format acceptable in the UE2 103, the UE2 103 generates in step 250 a new SDP offer (a type of counter-offer) indicating its acceptable maximum image format and sends it to the UE1 101.
In the above-described process, however, a receiving UE, which has received an image that the sending UE transmitted after encoding, may display the received image on its screen in a format different from the image format used during the encoding. One reason is to permit a customized display that is preferable to the user.
FIG. 3 is a diagram illustrating exemplary screens of two UEs (or mobile video telephones) now in operation.
In FIG. 3, a sending UE has encoded and transmitted an image in QCIF (176×144), but a format in which the image is actually displayed on a screen of a receiving UE has a size of about 240×200. In this particular case, the receiving UE decodes the received image in the encoding format of QCIF (176×144), and then enlarges the decoded image to 240×200, for the following reason. That is, because the receiving UE uses, as its screen, a Liquid Crystal Display (LCD) having a QVGA (320×240) resolution, if it intactly displays the received QCIF (176×144)-encoded image on its screen, the image shown may too small as compared with the size of the particular screen of the UE.
However, in this enlarging process, the following issues are sometimes encountered.
If the sending UE encodes an image in QCIF (176×144) as described above, the receiving UE may have a limitation in maintaining or improving the picture quality when enlarging the QCIF (176×144)-encoded image to 240×200, no matter how high it increases the bit rate.
In addition, this enlarging process should perform interpolation and filtering for every frame, and the interpolation and filtering for the enlarging process requires huge amounts of calculation.
On the contrary, even though a sending UTE encodes and transmits an image in QVGA (320×240) or CIF (352×288) and a receiving UE reduces the transmitted image to match with a 240×200-image format, the receiving UE needs a sub-sampling and performs a filtering process that requires numerous calculations, with as a result, a considerable part of the image information transmitted after undergoing encoding may be lost. In wireless communication, the waste of such frequency resources is very inefficient and can hardly be permit due to the lack of extra resources.
In other words, there is a known problem in the art is in that there is a significant difference between the available size of an LCD of the mobile phone, and the QCIF, QVGA and CIF formats closely connected to the environment of the mobile phone, among the image formats used in the current signal processing system.
The second problem in the art is that it is not possible to utilize the given bit rate in various modes with the method of selecting one of the existing image formats. For example, even though the UE intends to encode an image in a (16:9) wide-screen mode, there is no such formats and if needed, it is necessary to standardize the desired formats individually, raising another problem.